Skip to content

feat: introduce JUnit5 extension #545

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 10 commits into from
Sep 21, 2021

Conversation

lburgazzoli
Copy link
Collaborator

No description provided.

@lburgazzoli lburgazzoli changed the title feat: introduce Junit5 extension feat: introduce JUnit5 extension Sep 16, 2021
@lburgazzoli lburgazzoli force-pushed the junit-ext-2 branch 2 times, most recently from 7165d2c to 19a95fa Compare September 16, 2021 17:13
@lburgazzoli
Copy link
Collaborator Author

@metacosm @csviri what do you think about this extension ?
I think it could be a basis for a testing framework for operator written using the java-operator-sdk

@metacosm
Copy link
Collaborator

I'm planning on looking at this today.

@lburgazzoli lburgazzoli marked this pull request as draft September 20, 2021 12:46
@csviri
Copy link
Collaborator

csviri commented Sep 20, 2021

I will take a look tomorrow morning

@metacosm
Copy link
Collaborator

Do you intend to make more changes, @lburgazzoli?

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class BaseConfigurationService extends AbstractConfigurationService {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't get this class. Why are we creating loggers this way?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This class is just used to be able to have a non-abstract implementation that can be used in the junit extension. I'm debating whether to just put the DefaultConfigurationService into core itself and get rid of this class completely but I'm not too sure of the impact on the quarkus extension…

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oki,
(will take a look on the quarkus side to understand these aspects better)

@csviri
Copy link
Collaborator

csviri commented Sep 21, 2021

@metacosm @csviri what do you think about this extension ?
I think it could be a basis for a testing framework for operator written using the java-operator-sdk

Starting to look. Would it be an idea to add description to the PR's such this, where we explain some problem statement, so what is we are solving? What do you think?

@@ -60,12 +54,14 @@ protected void throwExceptionOnNameCollision(
final var key = keyFor(controller);
final var configuration = configurations.get(key);
if (configuration == null) {
log.warn(
"Configuration for controller '{}' was not found. {}", key, getControllersNameMessage());
logMissingControllerWarning(key, getControllersNameMessage());
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to my understanding, why is this better?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The benefit is minimal, indeed, just to be able to not pull SLF4J when using AbstractConfigurationService.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, isn't this a little bit over-engineering? We use SLF4J everywhere, and it's quite an industry standard

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The other issue is also that the previous version hardcoded the name of the logger, which might not have been appropriate depending on the actual implementation being executed (for example, even the Quarkus implementation would have logged something with Default ConfigurationService implementation logger name).

@lburgazzoli lburgazzoli marked this pull request as ready for review September 21, 2021 08:24

@Override
public void beforeAll(ExtensionContext context) throws Exception {
before(context);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we execute this before all? Should be this either before each or before all but not both?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the invocation depend on how you instantiate the extension:

  • if static --> beforeAll
  • if non static --> beforeEach

(at least that is my understanding)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ahh, ok, thank you!

@@ -135,6 +135,7 @@ protected void before(ExtensionContext context) {
namespace += "-";
namespace += context.getRequiredTestMethod().getName();
namespace = KubernetesResourceUtil.sanitizeName(namespace).toLowerCase(Locale.US);
namespace = namespace.substring(0, Math.min(namespace.length(), 63));
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So the length is not taken into account in sanitizeName? That sounds like a fabric8 bug to me…

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct, what it does is:

name.replaceAll("[^A-Za-z0-9]+", "-")

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, just saw that, will fix it now :)

@csviri
Copy link
Collaborator

csviri commented Sep 21, 2021

In general I like this idea, looks good, makes the tests more readable. Hopefully won't make it more complex to understand the framework/tests for newcomers.

@metacosm metacosm merged commit d518ee3 into operator-framework:master Sep 21, 2021
@metacosm metacosm deleted the junit-ext-2 branch September 21, 2021 08:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants